home *** CD-ROM | disk | FTP | other *** search
- Path: cs.mu.OZ.AU!bounce-back
- From: kanze@gabi-soft.fr (J. Kanze)
- Newsgroups: comp.std.c++
- Subject: Re: Standard string class
- Date: 20 Feb 96 05:41:50 GMT
- Organization: GABI Software, S`rl.
- Approved: fjh@cs.mu.oz.au
- Message-ID: <KANZE.96Feb19122908@gabi.gabi-soft.fr>
- References: <199602171134.LAA00305@kauri.vuw.ac.nz>
- NNTP-Posting-Host: munta.cs.mu.oz.au
- X-Original-Date: 19 Feb 1996 11:29:08 GMT
- In-Reply-To: robert.davies@vuw.ac.nz's message of 18 Feb 1996 02:14:33 GMT
- X-Auth: PGPMoose V1.1 PGP comp.std.c++
- iQBFAgUBMSlgVuEDnX0m9pzZAQEvbQF+O9GDLsNuCxZPLoFedS3qg7tbYbtUmfhs
- H9zdnG2N/GVLdHW946eHRfWVmY9Wrvvc
- =0ckm
- Originator: fjh@munta.cs.mu.OZ.AU
-
- In article <199602171134.LAA00305@kauri.vuw.ac.nz>
- robert.davies@vuw.ac.nz (Robert Davies) writes:
-
- |> Here are some comments and a query about the standard string class. I am
- |> working from the January 96 working papers, but the comments also apply to
- |> the April 95 version of the standard.
-
-
- |> Reallocation
- |> ------------
-
- |> Under the section on reserve the draft standard says that no reallocation
- |> of the storage takes place during insertions until the string reaches
- |> the length given by the last call of reserve. The standard does not say
- |> what insertion means. I assume it means append, +=, and possibly insert
- |> statements. Is this correct? If so the value returned by data() should
- |> remain valid following a call of append, += or insert if the string doesn't
- |> exceed the length set by reserve.
-
- |> But this is conflict with the description of data() which says the value
- |> returned becomes invalid after any non-constant call to the string
- |> concerned.
-
- |> Am I missing something or does this still need to be worked out?
-
- |> ...recommendation: this be clarified
-
- My feeling is that this is more a problem in getting all of the wording
- right than anything else. Personally, I would like to see a global
- statement as to when iterators, references and pointers become invalid,
- rather than have the cases enumerated at each function. Something along
- the lines of the following would seem to be the intent.
-
- An iterator into a basic_string, a reference returned by the member
- functions at or operator[] or a pointer returned by the member
- functions c_str and data, may be invalidated by any of the
- following:
-
- 1. Calling a non-const member function on the string, unless
- `reserve' has been previously called, in which case, they will
- only be invalidated if the non-const member function causes
- the string to become longer than the reserved size.
-
- 2. Calling either c_str or data.
-
- 3. Using the string as an argument to the member function swap.
-
- I personally think that one could add assigning to the string, i.e.: an
- operator= undoes the effect of reserve. There is nothing in the current
- draft that lets me think that this was the intent, however.
-
- I would prefer seeing this defined purly in terms of validity of
- reference, without mention of possible reallocation.
-
-
- |> at and operator[]
- |> -----------------
-
- |> The same comments apply here as applied to data() in my comments on
- |> reallocation.
-
- |> Are we to assume that
- |> x[3] = 'a';
- |> as an example, may cause a reallocation, and so invalidate data()?
-
- |> at and operator[] seem almost identical except that operator[] isn't
- |> required to check bounds. However, the const version of x[x.size()] is
- |> supposed to return traits::eos(), so if we store our strings without a
- |> trailing traits::eos() we will have to check bounds. Is this is what is
- |> intended?
-
- Another interesting question is the meaning of "x[ x.size() ] = 'a'".
-
- |> The constant version of operator[] returns a charT whereas the constant
- |> version of at returns a const_reference. What is the point of this
- |> difference and what effect does it have?
-
- |> ...recommendation: remove the requirement that x[x.size()] return
- |> traits::eos() and clarify the difference between operator[] and
- |> at.
-
- |> Question: are we safe to assume that something = x[3] will use the constant
- |> version of the operator?
-
- Definitly not. Whether the const or non-const version will be used
- depends entirly upon whether x is const or not.
-
-
- |> reallocation again
- |> ------------------
-
- |> Suppose I am right in thinking we can update a string with operator[], at,
- |> insert or append without causing reallocation.
-
- As I interpret the intent, this is true if and only if you have called
- reserve. These functions are non-const.
-
- |> Suppose also we are writing a string package with copy-on-write. Then
- |> copy-on-write must be disabled on string for which data() etc has been
- |> called. We need some way of telling a program that copy-on-write can be
- |> reactivated - eg we are no longer interested in the value returned by
- |> data(). Calling reserve() as I have defined above may be one
- |> possibility.
-
- Why does copy-on-write have to be disabled when data is called? Any
- non-const function (which might trigger copy-on-write) should invalidate
- the pointer.
-
- The one place I think copy-on-write must be disabled is precisely
- reserve. Since by calling reserve, I have guaranteed no further
- allocations (no pointer invalidation) as long as the length remains
- inferior to the capacity.
-
- |> ... recommendation: some way be found for allowing a user to re-instate
- |> copy-on-write.
-
- This is the purpose behind my suggestion that assignment `undo' the
- effects of reserve.
-
- It would probably also be worth mentioning that copy on write cannot be
- used if the allocators of the two strings compare different. I think
- that this is implicit in the current wording, and I'm not quite sure how
- to put it into legalese, either, but I think it must be clear;
- otherwise, what is the purpose of having the allocators? (Note that
- this is not a problem for string and wstring, since they both use the
- default allocator, and all instances of the default allocator compare
- equal.)
- --
- James Kanze (+33) 88 14 49 00 email: kanze@gabi-soft.fr
- GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
- Conseils, itudes et rialisations en logiciel orienti objet --
- -- A la recherche d'une activiti dans une region francophone
- ---
- [ To submit articles: try just posting with your news-reader.
- If that fails, use mailto:std-c++@ncar.ucar.edu
- FAQ: http://reality.sgi.com/employees/austern_mti/std-c++/faq.html
- Policy: http://reality.sgi.com/employees/austern_mti/std-c++/policy.html
- Comments? mailto:std-c++-request@ncar.ucar.edu.
- ]
-